Enterprise resource planning (ERP) software has generally been directed to supporting a broad set of business functions, including, for instance, product planning, purchasing, inventory maintenance, order tracking, supplier interaction, customer service, accounting, and human resources. Support of such functions has, in turn, been useful in a wide array of business areas, including, for instance, manufacturing, distribution, supply chain management, project management, financial management, personnel management, business analysis, enterprise portals, and commerce gateways. One example of an ERP system capable of such wide-ranging utility is Microsoft® Business Solutions-Axapta®, more recently commercially available as Microsoft Dynamics AX.
ERP software and other business applications have typically included or relied upon a database management system (DBMS) to handle the storage of the often vast amounts of enterprise data involved with each disparate business area supported thereby. The SQL Server® data management and analysis platform commercially available from Microsoft Corp. provides one such DBMS. Due to the wide-ranging nature of the data, the DBMS has often relied upon complicated data schema to store application metadata, which, in turn, described and specified the nature of the enterprise data. In this way, the metadata for a business application could be used to define the relationships underlying, for example, tables and fields that present, in an organized fashion, specific subsets of the enterprise data, such as the data underlying the generation of customized reports detailing customer sales orders or inventory information.
In some business applications, the metadata is additionally arranged in the form of a semantic model. The semantic model describes the data sources and relationships of the enterprise data. More specifically, each semantic model specifies the familiar names for the data fields (e.g., employee name, address, social security number, etc.), as well as mapping information to bind each object in the semantic model (e.g., employee address) to a data source or location. Without the semantic model, the information identifying the data source or location may be too cryptic for a typical user defining new views, reports, etc. of the data. Use of the semantic models also helps support user-friendly APIs that avoid forcing users to write program code, such as SQL or other database queries, to select and retrieve the data from the database.
Semantic models have also been used to specify information regarding relationships between other application metadata, as well as information about how the stored application metadata is analyzed. Other information has also been stored in semantic models, such as navigation information. In these ways, semantic models effectively place a layer on top of business application metadata, so that the business data can be properly understood, navigated, analyzed, etc. The use of semantic models therefore allows end user interfaces to be developed that avoid the potentially complex database query definitions or cryptic data source names that otherwise define the subsets of data to be presented in reports or other views of the database.
Business applications having extensive data handling requirements have relied on an independent DBMS to help manage application data. Using a separate, independent DBMS allows application designers to rely on the DBMS to handle complicated bulk data storage functions, while freeing designers to focus on creating application-specific functions.
But the use of a separate DBMS presents security challenges. First, the security functionality of a typical DBMS is often unsuited to handle application-specific security requirements. For example, the DBMS provided by Microsoft® SQL Server® provides protection of data at the table and column levels. Many business applications require more detailed protection distinguishing business data on, for instance, a row-by-row basis. In such row-level security, business data may be presented with certain rows hidden or withheld based on a user's role or security privileges.
To address this shortcoming of independent DBMS-based solutions, data access and data security have been managed through security rules established via the business application. Specifically, a system administrator or other user is authorized to establish a number of security rules that, in turn, specify the access privileges of each user of the business application. In this way, the business application is then configured as a gateway for granting or denying access to various subsets or other portions of the database. The security of the database is then maintained by permitting database access only through the business application itself. As a result, the security infrastructure established via the configuration of the business application provides a solution localized to the business application.
As long as use of the database is limited to within the business application, the security rules are enforced. Unfortunately, there is often a desire or need for data analysis for which the business application is not suited or designed. In some cases, the business application has been modified to include such data analysis functionality via, for instance, designing a module to extract and process the relevant data. But designing the necessary APIs and other aspects of the module may be unsuitably time consuming and complex, especially for many typical end users of the business application not possessing the requisite programming skills.
More often, such additional data analysis is addressed via an ad-hoc query or OLAP (Online Analytical Processing) module. OLAP generally supports customized views of the business data for a variety of business intelligence purposes, such as the data reporting, modeling, and other processing involved in discovering business trends. But in order to enforce the security rules applied to control access to the data, a system administrator must typically recreate those same rules in the metadata used to support the ad-hoc query or OLAP module. Such replication of the security rules is not only inefficient, but also prone to error. The risk of discrepancies with the security rules of the business application could also increase with the complexity of the security rules, the enterprise, etc.
Complicating matters further, the processing of the data for business intelligence purposes typically involves large-scale data retrieval. Unfortunately, the servers typically used to implement the business application are not designed or configured to support such data retrieval in an efficient manner. For example, business application servers are often not capable of the bulk data retrieval functionality by external servers utilizing the Open Database Connectivity (ODBC) standard API. And in cases where this capability has been available, such data retrieval has not typically enforced the business application security rules. Thus, access to the data through the business application server has been established either without enforcement of the security rules or using an unsuitably slow and inefficient solution having security rule enforcement.